…stat

Second round of compute-engine speedups on top of the previous commit; output stays byte-identical (quantized-equal / CID-stability contract).

Vectorize the per-chain median-CDR3-length stat (_median_cdr3_length_by_chain) with a polars count_matches over standard-AA chars instead of one effective_length Python call per row — the largest antibody-mode stats cost. Median formula unchanged, so stats.json is byte-identical.

Row-parallelize the pI bisection (isoelectric_point / fv_isoelectric_point): contiguous, data-independent row blocks bisected on separate threads (numpy elementwise releases the GIL), concatenated in row order. Each row's bisection depends only on its own counts, so the result is bit-identical regardless of worker count.

With both, antibody now scales with cores (~1.13x -> ~1.53x on 4 cores; 10.0s -> 4.6s at 1M rows), so the workflow scales antibody CPU up to 4 as well (it was pinned to cpu(1) when the mode did not parallelize). Both modes now share the same cpuFormula.

Add a determinism test above vectorized._PARALLEL_MIN_ROWS (antibody, exercising both isoelectric_point and fv_isoelectric_point) asserting byte-identical output at 1 vs 4 threads; the smaller cases stay under the parallel threshold and cannot reach it.

Verified: 262 software tests pass; output byte-identical vs the pre-change implementation (peptide + antibody at 1M) and across 1 vs 4 threads at scale.

…equence OOM

The lineCount-only memFormula under-provisioned low-row/long-sequence inputs: peak RSS is dominated by O(total-residues) cleaning transients (the DIWV weight gather, residue-row ids, byte buffers), which lineCount does not see. An amplicon-like 200k-row x ~600aa input peaks at 4.51 GiB but the old formula sized it to 200k*5KiB -> the 2 GiB floor, an OOM the pre-change flat 12 GiB avoided.

Add a residue-scaled term size("input.tsv") * 64 (measured ~40 B peak RSS per input byte; 64x for headroom) and take max() with the row-scaled lineCount term, so each dominates in its regime: short sequences use the row term (no change), long sequences use the size term. Verified: amplicon case now sizes to ~7.25 GiB >= 4.51 GiB peak; normal peptide/antibody sizing is unchanged (row term still dominates).

Review follow-ups #3 and #4, both byte-identical (no numeric or output change).

#3: _charge_raw takes an optional precomputed ten_ph; fv_isoelectric_point computes 10**ph once and shares it across both chains instead of recomputing the array-wide transcendental twice per Fv bisection step. Same value -> bit-identical.

#4: build the median-CDR3 count_matches character class from STANDARD_AAS (_STANDARD_AA_CLASS) instead of a hardcoded 40-char literal, so it cannot drift from properties.effective_length / the count substrate. Same class -> bit-identical.

Also softened the _charge_raw docstring's absolute 'bytes/CID unchanged' to 'within the quantized-equal contract' (review #5): the FP drift is byte-identical on the corpus but a knife-edge bisection midpoint within ~1e-15 of zero is a rare theoretical exception.

Verified: 262 tests pass, ruff clean, output byte-identical vs prior HEAD on antibody 1M (exercises both the Fv pI path and the median-CDR3 stat).

…t the static cap

Resolves review #2 (thread oversubscription). The workflow pinned POLARS_MAX_THREADS to the static cap (computeCpu=4) while cpuFormula grants 1..4 cores dynamically, and vectorized._n_workers() reads POLARS_MAX_THREADS to size the pI-bisection pool. So a sub-cap input (>=50k but <250k rows -> 1 core granted) spawned 4 polars + 4 bisection threads on a 1-core quota.

Set it instead with envExpr("POLARS_MAX_THREADS", "{system.cpu}"): the backend's command-expression engine substitutes the resolved quota grant (ComputeLimitsInfo.CPU = the cpuFormula result) before the process starts, so main.py reads the true granted core count at import. Gated on feats.commandExpressions with a static env(string(computeCpu)) fallback for older backends. This also removes the leaky reuse of the static cap and keeps the thread count in lockstep with the CPU reservation.

Verified: workflow tengo compiles (feats/envExpr), 262 tests pass. The runtime {system.cpu} substitution resolves at execution time, so it needs the live-backend integration test to exercise end-to-end.

Changeset: split the memory/CPU/threads wall into one-idea paragraphs (memory, CPU, determinism), convert the compute-optimization run-in list to scannable bullets, cut wordiness, and drop repeated byte-identity claims.

Comments: make the aa_fraction build comment active voice ('is unpivoted'/'are made contiguous' -> active), and fix a stale _n_workers docstring (POLARS_MAX_THREADS is the granted cores now, not the static cpu() request). No code changes; ruff + tests green.